home *** CD-ROM | disk | FTP | other *** search
/ Halting the Hacker - A P…uide to Computer Security / Halting the Hacker - A Practical Guide to Computer Security.iso / rfc / rfc1333.txt < prev    next >
Text File  |  1997-04-01  |  30KB  |  956 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         W. Simpson
  8. Request for Comments: 1333                                    Daydreamer
  9.                                                                 May 1992
  10.  
  11.  
  12.  
  13.                       PPP Link Quality Monitoring
  14.  
  15.  
  16.  
  17. Status of this Memo
  18.  
  19.    This RFC specifies an IAB standards track protocol for the Internet
  20.    community, and requests discussion and suggestions for improvements.
  21.    Please refer to the current edition of the "IAB Official Protocol
  22.    Standards" for the standardization state and status of this protocol.
  23.    Distribution of this memo is unlimited.
  24.  
  25. Abstract
  26.  
  27.    The Point-to-Point Protocol (PPP) [1] provides a standard method of
  28.    encapsulating Network Layer protocol information over point-to-point
  29.    links.  PPP also defines an extensible Link Control Protocol, which
  30.    allows negotiation of a Quality Protocol for continuous monitoring of
  31.    the viability of the link.
  32.  
  33.    This document defines a protocol for generating Link-Quality-Reports.
  34.  
  35.    This RFC is a product of the Point-to-Point Protocol Working Group of
  36.    the Internet Engineering Task Force (IETF).  Comments on this memo
  37.    should be submitted to the ietf-ppp@ucdavis.edu mailing list.
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                                                         [Page i]
  59.  
  60. RFC 1333              PPP Link Quality Monitoring               May 1992
  61.  
  62.  
  63. Table of Contents
  64.  
  65.  
  66.      1.     Introduction ..........................................    1
  67.  
  68.      2.     Link Quality Monitoring ...............................    2
  69.         2.1       Design Motivation ...............................    2
  70.         2.2       Counters ........................................    2
  71.         2.3       Counting Packets and Octets .....................    4
  72.         2.4       Processes .......................................    4
  73.         2.5       Configuration Option Format .....................    6
  74.         2.6       Packet Format ...................................    8
  75.         2.7       Transmission of Reports .........................   12
  76.         2.8       Calculations ....................................   12
  77.         2.9       Failure Detection ...............................   13
  78.         2.10      Policy Suggestions ..............................   14
  79.  
  80.      SECURITY CONSIDERATIONS ......................................   14
  81.  
  82.      REFERENCES ...................................................   14
  83.  
  84.      ACKNOWLEDGEMENTS .............................................   14
  85.  
  86.      CHAIR'S ADDRESS ..............................................   15
  87.  
  88.      AUTHOR'S ADDRESS .............................................   15
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Simpson                                                        [Page ii]
  115.  
  116. RFC 1333              PPP Link Quality Monitoring               May 1992
  117.  
  118.  
  119. 1.  Introduction
  120.  
  121.    PPP has three main components:
  122.  
  123.       1. A method for encapsulating datagrams over serial links.
  124.  
  125.       2. A Link Control Protocol (LCP) for establishing, configuring,
  126.          and testing the data-link connection.
  127.  
  128.       3. A family of Network Control Protocols (NCPs) for establishing
  129.          and configuring different network-layer protocols.
  130.  
  131.    In order to establish communications over a point-to-point link, each
  132.    end of the PPP link must first send LCP packets to configure the data
  133.    link during the Establishment phase.  During the Authentication and
  134.    Network-Layer Protocol phases, the link may be tested to determine if
  135.    quality is sufficient for operation.  This testing is completely
  136.    optional.
  137.  
  138.    If an implementation desires that the peer use some specific link
  139.    quality monitoring protocol, then it MUST negotiate the use of that
  140.    protocol using the Quality-Protocol Configuration Option during Link
  141.    Establishment phase.
  142.  
  143.    The negotiation mechanism is independent in each direction.  However,
  144.    if the peer agrees to send Quality-Protocol packets, it MUST
  145.    correctly process such packets on reception, even if it does not
  146.    request such packets or implement a monitoring policy.
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Simpson                                                         [Page 1]
  171.  
  172. RFC 1333              PPP Link Quality Monitoring               May 1992
  173.  
  174.  
  175. 2.  Link Quality Monitoring
  176.  
  177.    Data communications links are rarely perfect.  Packets can be dropped
  178.    or corrupted for various reasons (line noise, equipment failure,
  179.    buffer overruns, etc.).  Sometimes, it is desirable to determine
  180.    when, and how often, the link is dropping data.  Routers, for
  181.    example, may want to temporarily allow another route to take
  182.    precedence.  An implementation may also have the option of
  183.    disconnecting and switching to an alternate link.  The process of
  184.    determining data loss is called "Link Quality Monitoring".
  185.  
  186. 2.1.  Design Motivation
  187.  
  188.    There are many different ways to measure link quality, and even more
  189.    ways to react to it.  Rather than specifying a single scheme, Link
  190.    Quality Monitoring is divided into a "mechanism" and a "policy".  PPP
  191.    fully specifies the "mechanism" for Link Quality Monitoring by
  192.    defining the Link-Quality-Report (LQR) packet and specifying a
  193.    procedure for its use.  PPP does NOT specify a Link Quality
  194.    Monitoring "policy" -- how to judge link quality or what to do when
  195.    it is inadequate.  That is left as an implementation decision, and
  196.    can be different at each end of the link.  Implementations are
  197.    allowed, and even encouraged, to experiment with various link quality
  198.    policies.  The Link Quality Monitoring mechanism specification
  199.    insures that two implementations with different policies may
  200.    communicate and interoperate.
  201.  
  202.    To allow flexible policies to be implemented, the PPP Link Quality
  203.    Monitoring mechanism measures data loss in units of packets, octets,
  204.    and Link-Quality-Reports.  Each measurement is made separately for
  205.    each half of the link, both inbound and outbound.  All measurements
  206.    are communicated to both ends of the link so that each end of the
  207.    link can implement its own link quality policy for both its outbound
  208.    and inbound links.
  209.  
  210.    Finally, the Link Quality Monitoring protocol is designed to be
  211.    implementable on many different kinds of systems.  Although it may be
  212.    common to implement PPP (and especially Link Quality Monitoring) as a
  213.    single software process, multi-process implementations with hardware
  214.    support are also envisioned.  The PPP Link Quality Monitoring
  215.    mechanism provides for this by careful definition of the Link-
  216.    Quality-Report packet format, and by specifying reference points for
  217.    all data transmission and reception measurements.
  218.  
  219. 2.2.  Counters
  220.  
  221.    Each Link Quality Monitoring implementation maintains counts of the
  222.    number of packets and octets transmitted and successfully received,
  223.  
  224.  
  225.  
  226. Simpson                                                         [Page 2]
  227.  
  228. RFC 1333              PPP Link Quality Monitoring               May 1992
  229.  
  230.  
  231.    and periodically transmits this information to its peer in a Link-
  232.    Quality-Report packet.
  233.  
  234.    These counters are similar to sequence numbers; they are constantly
  235.    increasing to give a "relative" indication of the number of packets
  236.    and octets communicated across the outbound link.  By comparing the
  237.    values in successive Link-Quality-Reports, an LQR receiver can
  238.    compute the "delta" number of packets and octets successfully
  239.    communicated across the link.  Comparing these absolute numbers then
  240.    gives an indication of a link's quality.  Relative numbers, rather
  241.    than absolute, are transmitted because they greatly simplify link
  242.    synchronization.
  243.  
  244.    The Link-Quality-Report uses the Interface counters defined by SNMP
  245.    MIB-II [2].  These counters are not initialized to any particular
  246.    value when the LCP enters the Establishment phase.
  247.  
  248.    In addition, the Link-Quality-Report requires the implementation of
  249.    the following three unsigned, monotonically increasing counters which
  250.    conform to the type and size requirements for SNMP MIB Counters [3].
  251.  
  252.    OutLQRs
  253.  
  254.       OutLQRs is a 32-bit counter which increases by one for each
  255.       tranmitted Link-Quality-Report packet.  This counter MUST be set
  256.       to zero when the LCP enters the Establishment phase, and MUST NOT
  257.       be reset until the LCP leaves the Termination phase.  This counter
  258.       is incremented before it is inserted into the LQR packet.
  259.  
  260.    InLQRs
  261.  
  262.       InLQRs is a 32-bit counter which increases by one for each
  263.       received Link-Quality-Report packet.  This counter MUST be set to
  264.       zero when the LCP enters the Establishment phase, and MUST NOT be
  265.       reset until the LCP leaves the Termination phase.  This counter is
  266.       incremented before it is inserted (in an implementation dependent
  267.       fashion) into the LQR packet.
  268.  
  269.    InGoodOctets
  270.  
  271.       InGoodOctets is a 32-bit counter which increases by the number of
  272.       octets in each successfully received Data Link Layer packet.
  273.       Unlike the MIB ifInOctets, octets for frames which are counted in
  274.       ifInDiscards and ifInErrors MUST NOT be counted.  This counter MAY
  275.       be set to any initial value when the LCP enters the Establishment
  276.       phase, but MUST NOT be reset until the LCP leaves the Termination
  277.       phase.
  278.  
  279.  
  280.  
  281.  
  282. Simpson                                                         [Page 3]
  283.  
  284. RFC 1333              PPP Link Quality Monitoring               May 1992
  285.  
  286.  
  287. 2.3.  Counting Packets and Octets
  288.  
  289.    The intent of the counters is to provide an indication of the amount
  290.    of information passing over the link, rather than an actual
  291.    measurement of the total bandwidth used.  This specification is
  292.    designed to yield the same count in various circumstances, such as
  293.    when a separate device provides the framing and escaping mechanisms
  294.    invisibly to the implementation, or a synchronous-to-asynchronous
  295.    converter in the link changes between mechanisms.
  296.  
  297.    All octets which are included in the FCS calculation MUST be counted,
  298.    including the packet header, the information field, and any padding.
  299.    The FCS octets MUST also be counted, and one flag octet per frame
  300.    MUST be counted.  All other octets (such as additional flag
  301.    sequences, and escape bits or octets) MUST NOT be counted.
  302.  
  303.    When inserting the packet and octet counts in the LQR, the counts
  304.    MUST include the expected values for the LQR itself.
  305.  
  306. 2.4.  Processes
  307.  
  308.    The PPP Link Quality Monitoring mechanism is described using a
  309.    "logical process" model.  As shown below, there are five logical
  310.    processes duplicated at each end of the duplex link.
  311.  
  312.    +---------+   +-------+   +----+ Outbound
  313.    |         |-->|  Mux  |-->| Tx |=========>
  314.    | Link-   |   +-------+   +----+
  315.    | Manager |
  316.    |         |   +-------+   +----+ Inbound
  317.    |         |<--| Demux |<--| Rx |<=========
  318.    +---------+   +-------+   +----+
  319.  
  320.    Link-Manager
  321.  
  322.       The Link-Manager process transmits and receives Link-Quality-
  323.       Reports, and implements the desired link quality policy.  LQR
  324.       packets are transmitted at a constant rate, which is negotiated by
  325.       the LCP Quality-Protocol Configuration Option.
  326.  
  327.    Mux
  328.  
  329.       The Mux process multiplexes packets from the various protocols
  330.       (e.g., LCP, IP, XNS, etc.) into a single, sequential, and
  331.       prioritized stream of packets.  Link-Quality-Report packets MUST
  332.       be given the highest possible priority to insure that link quality
  333.       information is communicated in a timely manner.
  334.  
  335.  
  336.  
  337.  
  338. Simpson                                                         [Page 4]
  339.  
  340. RFC 1333              PPP Link Quality Monitoring               May 1992
  341.  
  342.  
  343.    Tx
  344.  
  345.       The Tx process maintains the MIB counters ifOutUniPackets and
  346.       ifOutOctets, and the internal counter OutLQRs, which are used to
  347.       measure the amount of data which is transmitted on the outbound
  348.       link.  When Tx processes a Link-Quality-Report packet, it inserts
  349.       the values of these counters into the corresponding PeerOut...
  350.       fields of the packet.  The Tx process MUST follow the Mux process
  351.       so that packets are counted in the order transmitted to the link.
  352.  
  353.    Rx
  354.  
  355.       The Rx process maintains the MIB counters ifInUniPackets,
  356.       ifInDiscards, ifInErrors and IfInOctets, and the internal counters
  357.       InLQRs and InGoodOctets, which are used to measure the amount of
  358.       data which is received by the inbound link.  When Rx processes a
  359.       Link-Quality-Report packet, it inserts the values of these
  360.       counters into the corresponding SaveIn... fields of the packet (in
  361.       an implementation dependent manner).
  362.  
  363.    Demux
  364.  
  365.       The Demux process demultiplexes packets for the various protocols.
  366.       The Demux process MUST follow the Rx process so that packets are
  367.       counted in the order received from the link.
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Simpson                                                         [Page 5]
  395.  
  396. RFC 1333              PPP Link Quality Monitoring               May 1992
  397.  
  398.  
  399. 2.5.  Configuration Option Format
  400.  
  401.  
  402.    Description
  403.  
  404.       Implementations MUST be prepared to receive the Quality-Protocol
  405.       Configuration Option for the Link-Quality-Report.  However,
  406.       negotiation is not required.  Negotiation is only necessary when
  407.       the implementation wishes to ensure that the peer transmits Link-
  408.       Quality-Reports as opposed to some other Quality-Protocol, or else
  409.       to prevent the peer from maintaining its own timer, or else to
  410.       establish a maximum time between transmissions of Link-Quality-
  411.       Reports.
  412.  
  413.    A summary of the Quality-Protocol Configuration Option format to
  414.    negotiate the Link-Quality-Report is shown below.  The fields are
  415.    transmitted from left to right.
  416.  
  417.     0                   1                   2                   3
  418.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  419.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  420.    |     Type      |    Length     |        Quality-Protocol       |
  421.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  422.    |                      Reporting-Period                         |
  423.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  424.  
  425.    Type
  426.  
  427.       4
  428.  
  429.    Length
  430.  
  431.       8
  432.  
  433.    Quality-Protocol
  434.  
  435.       c025 (hex) for Link-Quality-Report
  436.  
  437.    Reporting-Period
  438.  
  439.       The Reporting-Period field is four octets and indicates the
  440.       maximum time in hundredths of seconds between transmission of
  441.       packets.  The peer MAY transmit packets at a faster rate than that
  442.       which was negotiated.
  443.  
  444.       A value of zero indicates that the peer does not need to maintain
  445.       a timer.  Instead, the peer generates a LQR immediately upon
  446.       receiving a LQR.  A value of zero MUST be Nak'd by the peer with
  447.  
  448.  
  449.  
  450. Simpson                                                         [Page 6]
  451.  
  452. RFC 1333              PPP Link Quality Monitoring               May 1992
  453.  
  454.  
  455.       an appropriate non-zero value when that peer has sent or will send
  456.       a Configure-Request packet containing the Quality-Protocol
  457.       Configuration Option for the Link-Quality-Report with a zero
  458.       Reporting-Period.
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Simpson                                                         [Page 7]
  507.  
  508. RFC 1333              PPP Link Quality Monitoring               May 1992
  509.  
  510.  
  511. 2.6.  Packet Format
  512.  
  513.    Exactly one Link-Quality-Report packet is encapsulated in the
  514.    Information field of PPP Data Link Layer frames where the protocol
  515.    field indicates type hex c025 (Link-Quality-Report).  A summary of
  516.    the LQR packet format is shown below.  The names of the fields are
  517.    relative to the packet receiver, since it is the receiver who
  518.    requested the packet in the Configuration Option.  The fields are
  519.    transmitted from left to right.
  520.  
  521.     0                   1                   2                   3
  522.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  523.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  524.    |                         Magic-Number                          |
  525.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  526.    |                         LastOutLQRs                           |
  527.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  528.    |                        LastOutPackets                         |
  529.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  530.    |                        LastOutOctets                          |
  531.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  532.    |                         PeerInLQRs                            |
  533.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  534.    |                        PeerInPackets                          |
  535.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  536.    |                        PeerInDiscards                         |
  537.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  538.    |                        PeerInErrors                           |
  539.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  540.    |                        PeerInOctets                           |
  541.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  542.    |                         PeerOutLQRs                           |
  543.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  544.    |                        PeerOutPackets                         |
  545.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  546.    |                        PeerOutOctets                          |
  547.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  548.  
  549.    The following fields are not actually transmitted over the inbound
  550.    link.  Rather, they are logically appended (in an implementation
  551.    dependent manner) to the packet by the implementation's Rx process.
  552.  
  553.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  554.    |                         SaveInLQRs                            |
  555.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  556.    |                        SaveInPackets                          |
  557.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  558.    |                        SaveInDiscards                         |
  559.  
  560.  
  561.  
  562. Simpson                                                         [Page 8]
  563.  
  564. RFC 1333              PPP Link Quality Monitoring               May 1992
  565.  
  566.  
  567.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  568.    |                        SaveInErrors                           |
  569.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  570.    |                        SaveInOctets                           |
  571.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  572.  
  573.    Magic-Number
  574.  
  575.       The Magic-Number field is four octets and aids in detecting links
  576.       which are in the looped-back condition.  Unless modified by a
  577.       Configuration Option, the Magic-Number MUST be transmitted as zero
  578.       and MUST be ignored on reception.  If Magic-Numbers have been
  579.       negotiated, incoming LQR packets SHOULD be checked to ensure that
  580.       the local end is not seeing its own Magic-Number and thus a
  581.       looped-back link.  See the Magic-Number Configuration Option for
  582.       further explanation.
  583.  
  584.    LastOutLQRs
  585.  
  586.       The LastOutLQRs field is four octets, and is copied from the most
  587.       recently received PeerOutLQRs on transmission.
  588.  
  589.    LastOutPackets
  590.  
  591.       The LastOutPackets field is four octets, and is copied from the
  592.       most recently received PeerOutPackets on transmission.
  593.  
  594.    LastOutOctets
  595.  
  596.       The LastOutOctets field is four octets, and is copied from the
  597.       most recently received PeerOutOctets on transmission.
  598.  
  599.    PeerInLQRs
  600.  
  601.       The PeerInLQRs field is four octets, and is copied from the most
  602.       recently received SaveInLQRs on transmission.
  603.  
  604.       Whenever the PeerInLQRs field is discovered to be zero, the
  605.       LastOut... fields are indeterminate, and the PeerIn... fields
  606.       contain the initial values for the peer.
  607.  
  608.    PeerInPackets
  609.  
  610.       The PeerInPackets field is four octets, and is copied from the
  611.       most recently received SaveInPackets on transmission.
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Simpson                                                         [Page 9]
  619.  
  620. RFC 1333              PPP Link Quality Monitoring               May 1992
  621.  
  622.  
  623.    PeerInDiscards
  624.  
  625.       The PeerInDiscards field is four octets, and is copied from the
  626.       most recently received SaveInDiscards on transmission.
  627.  
  628.    PeerInErrors
  629.  
  630.       The PeerInErrors field is four octets, and is copied from the most
  631.       recently received SaveInErrors on transmission.
  632.  
  633.    PeerInOctets
  634.  
  635.       The PeerInOctets field is four octets, and is copied from the most
  636.       recently received SaveInOctets on transmission.
  637.  
  638.    PeerOutLQRs
  639.  
  640.       The PeerOutLQRs field is four octets, and is copied from OutLQRs
  641.       on transmission.  This number MUST include this LQR.
  642.  
  643.    PeerOutPackets
  644.  
  645.       The PeerOutPackets field is four octets, and is copied from the
  646.       current MIB ifOutUniPackets and ifOutNUniPackets on transmission.
  647.       This number MUST include this LQR.
  648.  
  649.    PeerOutOctets
  650.  
  651.       The PeerOutOctets field is four octets, and is copied from the
  652.       current MIB ifOutOctets on transmission.  This number MUST include
  653.       this LQR.
  654.  
  655.    SaveInLQRs
  656.  
  657.       The SaveInLQRs field is four octets, and is copied from InLQRs on
  658.       reception.  This number MUST include this LQR.
  659.  
  660.    SaveInPackets
  661.  
  662.       The SaveInPackets field is four octets, and is copied from the
  663.       current MIB ifInUniPackets and ifInNUniPackets on reception.  This
  664.       number MUST include this LQR.
  665.  
  666.    SaveInDiscards
  667.  
  668.       The SaveInDiscards field is four octets, and is copied from the
  669.       current MIB ifInDiscards on reception.  This number MUST include
  670.       this LQR.
  671.  
  672.  
  673.  
  674. Simpson                                                        [Page 10]
  675.  
  676. RFC 1333              PPP Link Quality Monitoring               May 1992
  677.  
  678.  
  679.    SaveInErrors
  680.  
  681.       The SaveInErrors field is four octets, and is copied from the
  682.       current MIB ifInErrors on reception.  This number MUST include
  683.       this LQR.
  684.  
  685.    SaveInOctets
  686.  
  687.       The SaveInOctets field is four octets, and is copied from the
  688.       current InGoodOctets on reception.  This number MUST include this
  689.       LQR.
  690.  
  691.       Note that InGoodOctets is not the same as the MIB ifInOctets
  692.       counter, as InGoodOctets does not include octets for packets which
  693.       are discards or errors.
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Simpson                                                        [Page 11]
  731.  
  732. RFC 1333              PPP Link Quality Monitoring               May 1992
  733.  
  734.  
  735. 2.7.  Transmission of Reports
  736.  
  737.    When the PPP Link Control Protocol has reached the Opened state, the
  738.    Link Quality Monitoring process MAY commence sending Link-Quality-
  739.    Reports.  If a Protocol-Reject is received specifying a LQR packet,
  740.    the LQM process MUST cease sending LQRs.
  741.  
  742.    Usually, the LQR is transmitted when the LQR timer for the link
  743.    expires.  If no LQR timer is used, a LQR is generated upon receipt of
  744.    an incoming LQR.  The negotiation process ensures that at least one
  745.    side of the link is using a LQR timer.
  746.  
  747.    In addition, a LQR is generated whenever two successive LQRs are
  748.    received which have the same PeerInLQRs value.  This may indicate
  749.    that a LQR has been missed, or that the implementation is sending at
  750.    a significantly slower rate than the peer, or that the peer has
  751.    accelerated LQR generation to better quantify errors on the link.
  752.  
  753.    Whenever a LQR is sent, the LQR timer MUST be restarted.
  754.  
  755. 2.8.  Calculations
  756.  
  757.    Each time a Link-Quality-Report packet is received from the inbound
  758.    link, the Link-Manager can compare the associated fields.  The fields
  759.    of the previous LQR can be subtracted from the current LQR values to
  760.    obtain an absolute "delta", which allows comparision of the changes
  761.    seen by each end of the link.
  762.  
  763.    If the received PeerInLQRs field is zero, the LastOut... fields are
  764.    indeterminate, and the PeerIn... fields contain the initial values
  765.    for the peer.  No calculations using these fields can be performed at
  766.    this time.
  767.  
  768.    Implementation Note:
  769.  
  770.       The following counters wrap to zero when their maximum value is
  771.       reached.  Care must be taken to ensure that correct "delta"
  772.       calculations are performed at that time.
  773.  
  774.    The LastOutLQRs field may be directly compared with the PeerInLQRs
  775.    field to determine how many outbound LQRs have been lost.
  776.  
  777.    The LastOutLQRs field may be directly compared with the OutLQRs
  778.    counter to determine how many outbound LQRs are still in the
  779.    pipeline.
  780.  
  781.    The change in PeerInPackets may be compared with the change in
  782.    LastOutPackets to determine the number of lost packets over the
  783.  
  784.  
  785.  
  786. Simpson                                                        [Page 12]
  787.  
  788. RFC 1333              PPP Link Quality Monitoring               May 1992
  789.  
  790.  
  791.    outgoing link.
  792.  
  793.    The change in PeerInOctets may be compared with the change in
  794.    LastOutOctets to determine the number of lost octets over the
  795.    outgoing link.
  796.  
  797.    The change in SaveInPackets may be compared with the change in
  798.    PeerOutPackets to determine the number of lost packets over the
  799.    incoming link.
  800.  
  801.    The change in SaveInOctets may be compared with the change in
  802.    PeerOutOctets to determine the number of lost octets over the
  803.    incoming link.
  804.  
  805.    The change in the PeerInDiscards and PeerInErrors fields may be used
  806.    to determine whether packet loss is due to congestion in the peer
  807.    rather than physical link failure.
  808.  
  809. 2.9.  Failure Detection
  810.  
  811.    When the link is operating well in both directions of the link, the
  812.    LQR is superfluous.  The maximum time interval for transmitting LQRs
  813.    SHOULD be chosen to minimally interfere with active traffic.
  814.  
  815.    When there is a measurable loss of data in either direction, if the
  816.    overall throughput is adequate, conditions are not severe enough to
  817.    warrant dropping the link.  Sending LQRs faster will gain nothing,
  818.    except to measure peaks in the loss rate.  The time interval MUST be
  819.    chosen to be long enough to have a good smoothing effect on the data,
  820.    while short enough to ensure fast enough response to complete
  821.    failure.
  822.  
  823.    When the link is good incoming, but very bad outgoing, incoming LQRs
  824.    indicate a high loss on the outgoing side of the link.  Sending LQRs
  825.    faster won't help, because they are probably lost on the way to the
  826.    peer.
  827.  
  828.    When the link is good outgoing, but very bad incoming, incoming LRQs
  829.    will be frequently lost.  In this case, LQRs SHOULD be sent at a
  830.    faster rate.  This primarily relies on the peer to make an informed
  831.    policy decision.  The peer will also send LQRs in response (due to
  832.    the duplicate PeerInLQRs field), and some of those LQRs may
  833.    successfully arrive.
  834.  
  835.    When a LQR does not arrive within the time expected, or the LQR
  836.    received indicates that the links are truly bad, at least one
  837.    additional LQR SHOULD be sent.  An algorithmic decision requires at
  838.    least 2 round trip intervals.  The loss rate could be transient, due
  839.  
  840.  
  841.  
  842. Simpson                                                        [Page 13]
  843.  
  844. RFC 1333              PPP Link Quality Monitoring               May 1992
  845.  
  846.  
  847.    to a heavily loaded link, or a lost outgoing LQR.
  848.  
  849. 2.10.  Policy Suggestions
  850.  
  851.    Link-Quality-Report packets provide a mechanism to determine the link
  852.    quality, but it is up to each implementation to decide when the link
  853.    is usable.  It is recommended that this policy implement some amount
  854.    of hysteresis so that the link does not bounce up and down.  One
  855.    policy is to use a K out of N algorithm.  In such an algorithm, there
  856.    must be K successes out of the last N periods for the link to be
  857.    considered of good quality.
  858.  
  859.    Procedures for recovery from poor quality links are unspecified and
  860.    may vary from implementation to implementation.  A suggested approach
  861.    is to immediately close all other Network-Layer protocols (i.e.,
  862.    cause IPCP to transmit a Terminate-Request), but to continue
  863.    transmitting Link-Quality-Reports.  Once the link quality again
  864.    reaches an acceptable level, Network-Layer protocols can be
  865.    reconfigured.
  866.  
  867. Security Considerations
  868.  
  869.    Security issues are not discussed in this memo.
  870.  
  871. References
  872.  
  873.    [1]   Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992.
  874.  
  875.    [2]   McCloghrie, K., and M. Rose, "Management Information Base for
  876.          Network Management of TCP/IP-based internets: MIB-II", RFC
  877.          1213, March 1991.
  878.  
  879.    [3]   Rose, M., and K. McCloghrie, "Structure and Identification of
  880.          Management Information for TCP/IP-based Internets", RFC 1155,
  881.          May 1990.
  882.  
  883. Acknowledgments
  884.  
  885.    Some of the text in this document is taken from RFC 1172, by Drew
  886.    Perkins of Carnegie Mellon University, and by Russ Hobby of the
  887.    University of California at Davis.
  888.  
  889.    Special thanks to Craig Fox (Network Systems), and Karl Fox (Morning
  890.    Star Technologies), for design suggestions based on implementation
  891.    experience.
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Simpson                                                        [Page 14]
  899.  
  900. RFC 1333              PPP Link Quality Monitoring               May 1992
  901.  
  902.  
  903. Chair's Address
  904.  
  905.    The working group can be contacted via the current chair:
  906.  
  907.       Brian Lloyd
  908.       Lloyd & Associates
  909.       3420 Sudbury Road
  910.       Cameron Park, California 95682
  911.  
  912.       Phone: (916) 676-1147
  913.  
  914.       EMail: brian@ray.lloyd.com
  915.  
  916.  
  917.  
  918. Author's Address
  919.  
  920.    Questions about this memo can also be directed to:
  921.  
  922.       William Allen Simpson
  923.       Daydreamer
  924.       Computer Systems Consulting Services
  925.       P O Box 6205
  926.       East Lansing, MI  48826-6025
  927.  
  928.       EMail: bsimpson@ray.lloyd.com
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Simpson                                                        [Page 15]
  955.  
  956.